PSU-Zhao-MC2

VAST 2012 Challenge
Mini-Challenge 2:

 

 

Team Members:

 

Mingyi Zhao, Penn State University, College of IST, muz127@psu.edu [PRIMARY contact]

Chen Zhong, Penn State University, College of IST, nju.chenzhong@gmail.com

Richard Ciamaichelo, Penn State University, College of IST, RJC5222@psu.edu

Michael Konek, Penn State University, College of IST, mck5111.psu@gmail.com

Neela Sawant, Penn State University, College of IST, nks125@ist.psu.edu

Nick Giacobe, Penn State University, College of IST, nxg13@ist.psu.edu



Student Team: Yes

 

Tool(s):

 

We used Perl to preprocess IDS and firewall logs. Then we used the Processing language to develop several visual analytic modules. We also used GeoViz toolkit and GeoDA to visualize our data. GeoViz toolkit is developed by the department of geography at Pennsylvania State University. GeoDA is developed by the GeoDA center at Arizona State University.

 

Video:

 

PSU-Zhao-MC2/ 

 

Answers to Mini-Challenge 2 Questions:

 

MC 2.1 Using your visual analytics tools, can you identify what noteworthy events took place for the time period covered in the firewall and IDS logs? Provide screen shots of your visual analytics tools that highlight the five most noteworthy events of security concern, along with explanations of each event.

1.    DNS Update from External Net
Time: 6:00 p.m. on April 5th and at 5:30 and 6:30 p.m. on April 6th
Source: a group of workstations (88 IP addresses, blue highlighted in Figure 1.3)
Destination: DNS server (172.23.0.10)
Description:

To get the situation awareness of the branch network, we first visualized the IDS alert counts of each hour as a time line graph in Figure 1.1. After highlighting several alerts, we identified “POLICY DNS Update from External net” happened in two time periods. To further investigate this alert, we used an event sequence graph (Figure 1.2). We found that this alert represents attacks from several workstations to the DNS server. Finally, we used the GeoViz toolkit to find out which workstations are responsible for this attack. Figure 1.3 shows the geographical distribution of all IPs in the IDS logs where IPs are grouped together by subnet. We found the coordinate information in Mini Challenge 1’s dataset and joined that data to ours by subnet locations. Workstations that are responsible for this attack are colored in blue. Interestingly, all these workstations belong to three subnets that are away from other subnets.


Description: Description: https://lh3.googleusercontent.com/pzZc8cw4b30lpUYWeNm-QmdR8tUee-RtGmvO1Nbse_F2g57gpoKQbXCeRBYQcklON_oC1ytcTgnIWmb4iGvB4KDCLCoBFh2Nlsaw0o0d-HTEVpEtMe4
Figure 1. 1.

Description: Description: https://lh5.googleusercontent.com/Ag6Bs5v7jQzqih4unRPPGZ6mg1TmmI8AOD3sphr1A9-2agW6aV25y0YMPuEU7nUxMZ4CrH6ViEL3tY-Dp3d69V_fRPAfVF0CM5J7vBEs6lFIQWtYnjo
Figure 1.2
Description: Description: https://lh5.googleusercontent.com/eMzFZUbrD4-uTZKeHN24YnELgZGYOMNCSnypRrs1ufWq2aWJDRi2iODYK1mfh4_mPj6l4bQSFqqxkULjDTYG5Ph1fRtaMdT9Dwhs2ZPlPF74E0jhYks
Figure
1.3


2.    Workstations Connected to Internet Websites and became Infected by the Adware
Time:
18:00 and 20:25, 4/5/2012
Source: Most of the workstations in the network (Red and green nodes in Figure 2.1)
Destination: Several Internet websites (Orange nodes in Figure 2.1)
Description:
After finding event 1, we started to look for the consequences of this DNS attack. By visualizing the firewall data we can see that the connections from the workstations to the Internet websites (message code ASA-6-302013 ) suddenly occurred after the DNS attack (Figure 1.4 & 1.5). Particularly, IP 172.23.0.132 had many connections to the Internet websites (Figure 1.5).

These connections became the entry points of the adware, because in Figure 1.1 & 1.6, alert “ET Policy IRC Authorization Message” started to occur after 20:25.  Since this alert is from Internet websites to workstations, we highly suspect that it corresponds to the warning message observed by the employees.



Description: Description: https://lh6.googleusercontent.com/qobV-kxAMbiByKFb5HN1B_NmsHBu-TQcsgrd8Zdf291AFBMCpVQ5p_r2cc5CVHcu84Wn1mioK0DhFIviZUg8gIZnHpaSi1jue91L70VtKlAgwpBLElo
Figure 1.4

Description: Description: https://lh5.googleusercontent.com/_vzMmDY42tTxpax4Q9VlOC2BcosbdciCx4mU2oxjxneZ5CZtMKX9-Ab1-4rnwoDTkdt34LcmQvLQgqBJ6BKXgw7pEx0SsWAaX8HkVUCFWOl_MgocRgc
Figure 1.5
Description: Description: https://lh5.googleusercontent.com/0cAFyHtRzmHxJ5KD1K0729KhKRqfJq3sLfzuZaf2QZ2F-GdBl2VHZXc9gbuC4Nw6fNuDFWOZx-_n9YZA1UO5frSiGfEx2bkrPqI36SLcPjQ1Y4DLI_4
Figure
1.6



3.  Denial of Service Attack to the HQ
Time: 5/5/2012 23pm
Source: Workstation 172.23.0.132
Destination: Corporate HQ Data Center 172.25.0.1
Description:
Interestingly, we found a possible DOS attack by visualizing the network connections from firewall log.  Figure 1.7 is the graph that shows the connection network in the 23rd hour of 5/5/2012.  The weight of the line corresponds to the connection number of two IP addresses. When there are more connections, the line is thicker. We can see a very thick line between workstation 172.23.0.132 and the Corporate HQ DataCenter's firewall 172.25.0.1. The workstation built and tears down the connection with the HQ firewall again and again at a very high rate.

Description: Description: https://lh4.googleusercontent.com/VPjr9jDd9TZ5rsmjM1kWgudlwTTjz5PVHSkXZm1S2NwRix2DsdiWAczl32UDG4TWRzJZrM-buH0uxAYiultobviULwdkVSCFWcD7eG10KY8jx15-Z5I
Figure 1.7

The sudden drop of the connection numbers in the 3rd hour of 5/5/2012 (Figure 1.4, Figure 1.8) makes the connection between the suspicious workstation and the Corporate HQ firewall more obvious.  Considering the Corporate HQ primarily hosts the mail system and the financial servers, we think the abnormal frequent connections are a DoS (Denial of service Attack), which is aimed to make the HQ systems unavailable to other workstations.

4. A Drop of Connection Count and IDS Alert Counts
Time: from 3pm to 6pm in 05/Apr/2012
Description:
In this hour, the connection numbers for the whole network experienced a sudden drop.  The figure below shows a comparison of the network connections in the hour before the 3:00 hour and the 3:00 hour itself (Figure 1.4 & 1.8). We can see clearly that there is a sudden drop in the total number of connections between workstations and the Internet websites and the DNS in this hour didn't connect to the DNS Root Server.  However, there are still a large number of connections from one suspicious workstation (172.23.0.132) to the HQ firewall. Therefore, we think the sudden drop is caused by the DoS attack
and the DNS update.

Description: Description: https://lh4.googleusercontent.com/Di-ElbtzhFaAMVTuhxLhyC0zY6OzHyyDAM0V0z2Dsbs8ODedAno14Qr7y9cZlz_CmGUzFu7O87i2vD1GPdZtK_OA2R061qh4-AqnX_HXKhDCtyhy1OEDescription: Description: https://lh4.googleusercontent.com/qjdS4oBHJb8jl9GfBRuoJ7BTj1iwWyvxZFaKp4eB8I2tPt_T6jQ7uihpcT5U1Ks71Wd99s9WH2EqG1dVh-Tvb2yD5xfoGbo8cYmco6rWLrA9ylr3n4Y

                                       Figure 1.8

5.    Brute Force Attacks and Port Scan

Time: 23pm 4/5/2012 and 0am 4/6/2012
Source:
Several Workstations (mainly from 172.23.231.29)
Destination:
Cisco ASA Firewall
Description:

During the midnight hours, several attacks and scans were attempted between infected workstations and the firewall (Figure 1.1). The connections were attempted through various SQL, VNC, SSH, and email ports, and personal information was trying to be obtained. Brute force attacks were aimed at the email protocols to gain information.

To identify workstations that are responsible for these attacks, we use the Parallel Coordinate Plot below (Figure 1.9) to show the number of times each alert was triggered during the midnight hour on April 6th. Each line represents an IP address with the highlighted line being the IP address of the firewall. Alerts 7 through 21 were sent to the firewall from one of three workstations.

Description: Description: https://lh3.googleusercontent.com/fmIGbkapuKgUV5OIIZGv51v0fm_tSlMBqno2eWTYjF-cDu-GEJcORSrBlBXkSO-P_qgpz8-q9_RigbvxL60CM_malQnRLrDACNqag5y-chwMuA52LPQ
Figure 1.9

MC 2.2 What security trend is apparent in the firewall and IDS logs over the course of the two days included here? Illustrate the identified trend with an informative and innovative visualization.

The security trend we observe is that the local DNS server is periodically and maliciously updated at approximately 6:00 p.m on the 5th and the 6th of April. Normal network traffic is redirected to the malicious Internet websites after the DNS is updated from the external net. This is the main reason why employees saw the adware popups. We use the following Cartogram (Figure 2.1) to show the status of the branch network in the three days covered in logs.

In Figure 2.1, The orange highlighted circles are IP addresses of Internet websites and every other circle represents an IP address on the bank network. Green circles are addresses that received Internet Relay Chat requests from the websites and red circles received the requests with more frequency.  We can see that some workstation nodes remain white, i.e., they are not infected by the adware during that time period.

Description: Description: https://lh4.googleusercontent.com/rHNKGre_Qq0ItahBRi6GAW_hJv4_QhNKja23vV6fs4ceGrf303kvYEd1rGxWcuiabtQ2jf41m4cZ91TUvQVrFA2TewFihT9Qgwhr_zN-O_wE54Axuz0
Figure 2.1

MC 2.3 what do you suspect is (are) the root cause(s) of the events identified in MC 2.1? Understanding that you cannot shut down the corporate network or disconnect it from the internet, what actions should the network administrators take to mitigate the root cause problem(s)?

We believe one of the root causes of the events is that several workstations (listed in MC2.1 event 1) got infected and launched DNS attack at 6pm of the April 5th. The exact reason they got infected is unclear. But from our geological visualization (Figure 1.3), we found out that these initially infected machines are all located in remote subnets of the bank branch. Perhaps these subnets are more vulnerable than others. After the DNS is altered, workstations’ requests were redirected to sites which were malicious and in turn infected those workstations within the network. Infected workstations were then instructed to find other vulnerabilities in the firewall by requesting connections to SQL, SSH, and VNC ports. We believe this is the cause of the Anti-virus Adware that pops up on the screens of the workstations. To mitigate this problem, we would (1) shut down and repair the workstations launching DNS attacks, (2) update firewall rules to block connections to the malicious websites from workstations and (3) fix the polluted DNS entries.